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Abstract 
We define Dynamic Host Configuration Protocol (DHCP) options being 
used by Preboot eXecution Environment (PXE) and Extensible Firmware 
Interface (EFI) clients to uniquely identify booting client machines 
and their pre-OS runtime environment so that the DHCP and/or PXE boot 
server can return the correct OS bootstrap image (or pre-boot 


application) name and server to the client. 
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Introduction 


These DHCP [2] options are being widely used by PXE-compliant clients 
to uniquely identify booting client machines themselves and their 
pre-OS runtime environment so that the DHCP and/or PXE boot server 
can return the correct OS bootstrap image (or pre-boot application) 
name and server to the client. In the past, this work was done by 
examining the network Media Access Code (MAC) address in the "chaddr" 
field in the BOOTP/ DHCP header and keeping a database of MAC 
addresses on the BOOTP/DHCP server. This was deemed insufficient for 
large and complex networks for two main reasons. 1) Multiple laptops 
could end up with the same MAC address if the network interface was 
in a shared docking station. 2) Multiple network devices and MAC 
addresses could be used by one machine for redundancy or because of 
repairs. Another issue that came up was the machine that could 
change its pre-OS runtime environment. This issue caused the 
creation of another new option to identify the runtime environment so 
that the correct binary image could be matched up with the booting 
machine. These options are defined by Intel in the PXE [3] and EFI 
[4] specifications and are being documented in this draft for 
completeness within the IETF. 


1. Requirements Language 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [1]. 
Option Definitions 
There are three DHCP options [5] defined for use by PXE clients. 
1. Client System Architecture Type Option Definition 


The format of the option is: 


Code Len 16-bit Type 
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Octet "n" gives the number of octets containing "architecture types" 
(not including the code and len fields). It MUST be an even number 
greater than zero. Clients that support more than one architecture 
type MAY include a list of these types in their initial DHCP and PXE 
boot server packets. The list of supported architecture types MAY be 
reduced in any packet exchange between the client and server(s). 
Octets "n1" and "n2" encode a 16-bit architecture type identifier 
that describes the pre-boot runtime environment (s) of the client 
machine. 


As of the writing of this document, the following pre-boot 
architecture types have been requested. 


Type Architecture Name 
Intel x86PC 
NEC/PC98 

EFI Itanium 

DEC Alpha 

Arc x86 

Intel Lean Client 
EFI IA32 

EFI BC 

EFI Xscale 

EFI x86-64 


OMDAINHDUAPWNFO 


This option MUST be present in all DHCP and PXE packets sent by PXE- 
compliant clients and servers. 


2.2. Client Network Interface Identifier Option Definition 
The format of the option is: 


Code Len Type Major Minor 


Octet "t" encodes a network interface type. For now the only 
supported value is 1 for Universal Network Device Interface (UNDI). 
Octets "M" and "m" describe the interface revision. To encode the 
UNDI revision of 2.11, "M" would be set to 2, and "m" would be set to 
11 (0x0B). 
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Revision Description 


< 2.00 LANDesk service agent boot ROMs. No PXE APIs. 
2.00 First generation PXE boot ROMs. (PXENV+) [3] 
2.01 Second generation PXE boot ROMs. (!PXE) [3] 
3.00 32/64-bit UNDI specification. (Alpha) [4] 


EFI boot services driver only. 
No EFI runtime support. 


3.10 32/64-bit UNDI specification. (Beta) [4] 
First generation EFI runtime driver support. 


3.20 32/64-bit UNDI specification. (Release) [4] 
Second generation EFI runtime driver support. 


This option MUST be present in all DHCP and PXE packets sent by PXE- 
compliant clients and servers. 


2.3. Client Machine Identifier Option Definition 
The format of the option is: 


Code Len Type Machine Identifier 


Octet "t" describes the type of the machine identifier in the 
remaining octets in this option. 0 (zero) is the only value defined 
for this octet at the present time, and it describes the remaining 
octets as a 16-octet Globally Unique Identifier (GUID). Octet "n" is 
17 for type 0. (One definition of GUID can be found in Appendix A of 
the EFI specification [4].) 


This option MUST be present in all DHCP and PXE packets sent by PXE- 
compliant clients and servers. 


2.4. Options Requested by PXE Clients 


All compliant PXE clients MUST include a request for DHCP options 128 
through 135 in all DHCP and PXE packets. The format and contents of 
these options are NOT defined by the PXE specification. These 
options MAY be present in the DHCP and PXE boot server replies and 
are meant for use by the downloaded network bootstrap programs. 

These options are NOT used by the PXE boot ROMs. 
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As options 128-135 are not officially assigned for PXE use (before 
November 2004 they were considered site-specific options, [6]), use 
of these option values for PXE may conflict with other uses of the 
same options on the same networks. 


3. Acknowledgements 
The authors thank Bernie Volz for valuable input. 

4. IANA Considerations 
IANA has updated the numbering space defined for public DHCP options 
in [7] with references to this document for options 93, 94, and 97 


(previously, there were references to [8]). Also, IANA marked 
options 128-135 as being used by PXE and referenced this document. 


5. Security Considerations 


By specifying incorrect values for some of these options, a client 
may get access to, and possibly attempt to execute, code intended for 
another platform or client. This may have security ramifications. 
Also note that these options contain information about a client’s 
system architecture and pre-OS runtime environment that is revealed 
to anyone who is able to listen in on DHCP messages sent by the 
client. This information may be of use to potential attackers. 
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This document is subject to the rights, licenses and restrictions 
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retain all their rights. 
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pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; nor does it represent that it has 
made any independent effort to identify any such rights. Information 
on the procedures with respect to rights in RFC documents can be 
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Copies of IPR disclosures made to the IETF Secretariat and any 
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http://www.ietf.org/ipr. 


The IETF invites any interested party to bring to its attention any 
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